The development of networking technologies facilitates the communication of various devices and makes it possible for an application to involve multiple devices. These devices, usually designed for different purposes, have different computing capabilities, memory capacity and power consumption. As a result, there are different requirements for these devices when they are involved in an application, such as file sharing and file downloading.
FIG. 1 illustrates an exemplary home networking environment in which a wireless access point is connected to the Internet (via a Network Address Translation (NAT) based router (network translation device)). There are also a network attached storage (NAS) device (destination storage device/storage device), a desktop computer and several wireless clients, e.g. laptop, personal digital assistant (PDA). As used herein “/” should be interpreted as denoting alternative names for a component. A file sharing application, in an exemplary environment as depicted in FIG. 1, involves four devices: the remote file (data) server (source data server/source device), the network attached storage (NAS), an access point and at least one mobile client (e.g. laptop or PDA). While the laptop and PDA are equipped with powerful CPUs and user friendly interfaces, they are not designed to be powered on all the time. On the other hand, the wireless access point and the NAS are usually small embedded systems with slower CPUs and less memory. They are powered on most of the time.
The communication protocol used by these devices is usually TCP. However, the end-to-end nature of TCP ties all participating devices together and requires them to be active for the duration of a session. Yet, not all devices are required all of the time. For example, a PDA may be used to initiate a file downloading. What is really desired is that the file is directly downloaded from the remote file (data) server (source device) to the NAS disk (storage device) such that the PDA can be suspended when the download begins. It may not be possible to instruct the NAS to do that directly for several reasons. First, the NAS might be a dumb device, which cannot be controlled to initiate connections. Second, the initial connection setup process might require complex authentication and thus human interaction, for example, filling in user name and password, interpreting a script (e.g. java script), or solving a graph puzzle.
Conventionally, multiple connections are set up and maintained in order for the application to work properly. However, there are several disadvantages with this approach. First, the requirement that all participants be active during a session limits the mobility of mobile devices. No device can be disconnected or suspended because the proper function of the application relies upon the active TCP end points/devices. However, it is not usually desirable to keep those devices powered on all the time. For example, it might be necessary or desirable to take the notebook computer to work or the PDA might have limited battery life. Second, redundant connections consume more resources. Power is consumed keeping those devices active; extra bandwidth is required to transmit data between devices; CPU cycles are required to perform checksum calculation; memory is required for buffering packets. Finally, the redundant connections usually do not increase the reliability and performance of the application but to the contrary, redundant connections introduce more points of failure, more bottle neck links and higher latency. For example, a wireless connection is often susceptible to packet loss and connection drop. The more wireless links an application involves, the less reliable the data communication actually is.
In prior art approaches, proxies were deployed on the network address translation device. A connection to the outside can be made and kept by the proxy. Multiple devices can first connect to the network address translation device and request the same connection. So a mobile device can set up a connection and instruct another device to use this connection. However, this approach only enables sharing of a connection among certain hosts; it does not decrease the number of connections. Moreover, some dumb devices (e.g. NAS) might not even be able to initiate a connection to the network address translation device. Furthermore, due to the extra number of connections on the network address translation device, the network translation device requires more resources, e.g. data copy and checksum calculation, packet buffering, etc. TCP splicing is a similar prior art approach, but its focus is on improving proxy performance for a connection between a client and a server. It only involves three devices: client, server and proxy. Msocks, another prior art approach, makes use of TCP splicing to solve the mobility problem of the same device, i.e. when a host moves, its connection is maintained at transport level. Msocks also requires changing the application on the mobile device to link with a special library.